Typically, application programs contain command sets that include individual commands that can be used by a user when working in a particular application program. These commands are specific to the purpose of the application program. For example, a word processing application program will typically include a command set that can be used to manipulate the text and/or format of a document. These command sets, however, are not always as easy to use as one would like. This situation can be complicated when a user is not familiar with the command set of an application program that they are currently Using.
Current problems with application program command sets include that they can be difficult to use or browse because of the large number of commands that can be included in a command set, and that they often times can temporarily obscure a document when a user attempts to use them. In addition, command sets are typically presented in a manner that is not related to the tasks in which the user might be engaged.
With respect to the browsing difficulty of command sets, consider the following. Command sets can typically contain many different commands that are available for use. Since, in a typical user display, there is only a limited amount of space to present information without undesirably obscuring a work area, it logically follows that not all commands can be displayed at all times for the user. To address this problem, solutions have included providing a static tool bar that can expose some commands and contain a menu structure that can be browsed by the user. Consider, for example, FIG. 1 which shows an exemplary user display 10 that includes a tool bar 12 that includes a menu structure 14 and a collection of commands 16. The menu structure 14 includes individual entries, e.g. “File”, “Edit”, “View”, “Insert”, etc. Each of these entries is associated with a drop down menu that contains a collection of individual commands that are logically related to their entry. For example, for the “File” entry, individual drop down menu-accessible commands include “new”, “open”, “close”, “print”, “print preview” and additional commands that are accessible via an “options” selection that further extends the drop down menu to display the additional commands. Each of the top line menu entries in the menu structure 14 can be associated with a drop down menu. Also, some of the commands are gathered into broad groups (such as the Font Formatting dialog) and the user needs to know what Font Formatting is, in order to find the commands in this group. Needless to say, the number of available commands can often times be quite numerous so that browsing through them is not an easy task. In addition, an inherent inefficiency with this approach is that many if not most of the displayed commands will have little or nothing to do with what the user is currently looking for. Often, in fact, many of the commands are grayed out and disabled because they are not relevant to the current task. Regardless, they are exposed to the full subset of commands.
Consider how this problem is exacerbated when a user is only moderately familiar or not familiar at all with an application program. Having to figure out and navigate through an extensive set of commands that are not explained (except for perhaps a “Help” dialog) can make the user's experience difficult and time consuming. In addition, many application programs are physically or logically tapped out as far as including additional commands. Specifically, in many application programs there are simply so many commands in the command set that including more commands would require the menu structure to include more “options” buttons that, in turn, would present more and more commands, thus requiring a user to physically navigate through more commands.
Additionally, many application programs display their command sets in a manner that can obscure the work area for the user. For example, consider FIG. 2 which shows a “Font” dialog box 18 that is presented in the middle of the user's work area. To get to this dialog box, the user had to click on the “Format” menu 11 entry in menu structure 14, and then select the “Font” command within the drop down menu that was presented. As a result the illustrated dialog box 18 is displayed. Although this is helpful for enabling a user to see an extensive list of commands, it is not optimal for a couple of different reasons. First, the user's document is partially obscured by the dialog box 18. This is undesirable because the user may wish to keep the work area in view. In addition, in order to work within the dialog box, the user has to quit working within their document. Thus, the dialog box is referred to as having “mode” or being “modal”, meaning that a user must enter into a particular mode that renders them unable to work within their document in order to work within the dialog box. Second, and perhaps more important, the user's command selection is not implemented immediately, and, even if it were, the document is obscured by the dialog box. Specifically, in order to have a command implemented, e.g. a “strikethrough” command, the user must select text in the document that they are working on and pull up the dialog box. Only after they click on the “strikethrough” box and on the “OK” box is the command implemented (this is somewhat related to the mode aspect mentioned above). In addition, if a user desires to implement a command on multiple different portions of text, they must separately select each text portion and apply the command for each selected portion of text. That is, for each portion of text, they must separately and individually pull up the appropriate dialog box to apply the command. This is not optimal.
Consider also the collection of commands 16. Many application programs provide such a feature where frequently used commands are displayed in a manner in which they can be quickly clicked on by a user and applied within the context of the application program. These commands are often presented as so-called “modeless” commands (as contrasted with “modal” commands) because they can be used while still working within a document. That is, in the illustrated example, individual commands from the collection include “bold”, “italics”, and “underline” commands. Yet, even though the goal of displaying these frequently-used commands is directed to improving user efficiency, this attempt falls short of the mark for the following reason. Even though the commands that are displayed might be considered as those that are most frequently used, their use occurrence may constitute only a very small portion of a user session, if at all. To this extent, having the commands displayed when they are not being used is wasteful in that valuable display real estate is consumed. This is a direct manifestation of the fact that the displayed commands have nothing to do with the specific context of the user. Yes—the user might in the course of their computing session have the need to use a particular command, but until that command is specifically needed by the user, its display bears no logical relation to the user's computing context.
Accordingly, this invention arose out of concerns associated with providing improved methods and systems for presenting command sets to users. Specifically, the invention arose out of concerns associated with providing methods and systems of presenting commands in a task-sensitive manner, which assist in using physical screen space in a more efficient manner.